This is quite exciting! I left a couple of specific comments below. Here let me go over the callsite-specialization issue that appears below and may be something to keep in mind more generally.

Let's compare two implementations of a simple "depot" function:

julia> function dotrig1(x, funcname)
           f = funcname == "sin" ? sin :
               funcname == "cos" ? cos :
               funcname == "tan" ? tan :
               funcname == "sec" ? sec : error("$funcname not supported")
           return f(x)
       end

julia> function dotrig2(x, funcname)
           funcname == "sin" && return sin(x)
           funcname == "cos" && return cos(x)
           funcname == "tan" && return tan(x)
           funcname == "sec" && return sec(x)
           error("$funcname not supported")
       end

Now compare:

using Cthulhu
@descend iswarn=true dotrig1(π/4, "sin")
@descend iswarn=true dotrig2(π/4, "sin")

You'll note that dotrig1 is inferred to return Any whereas dotrig2 is inferred to return Float64. What's happening here is callsite specialization: for dotrig1, there's a single place in the code that makes the f(x) call, and so the compiler has to allow that call to be generic: it inserts code that says, "OK, what is f? Can I find a compiled method for that f and that ::typeof(x)? If not, compile it; then run it." There's a lot of "state" that might affect the return type of f(x) and at a certain point Julia's type-inference just gives up. (It has to: type-inference is subject to the halting problem, so it has to have heuristics that self-terminate.)

In contrast, with dotrig2, there are 4 separate call sites for f(x), each corresponding to a different f. This allows the compiler to specialize each one of those sites differently, and since it knows the f with certainty it can fully specialize each one, precompile all the calls, and thus execute the function just by jumping to a specific known-in-advance memory address that gets hardwired into the compiled code. You can't get more efficient than that (well, with inlining you might, but the good news Julia will even do that if appropriate).

A related issue: if you have a list of functions that you want to apply to a lot of different variables, then

for x in varlist
    for f in funclist
        mysum += f(x)
    end
end

will be really bad, because there isn't a single call that can be predicted in advance: each and every one of those O(m*n) calls has to be individually analyzed ("what's f?"). In contrast,

for f in funclist
    mysum += apply_to_list(f, xlist)
end

@noinline apply_to_list(f::F, xlist) where F = sum(f, xlist)

forces Julia to specialize apply_to_list for each different f: Julia may not be able to predict which f will come out of flist, but once it figures that out it calls one of many different compiled versions of apply_to_list, each of which is specialized to a particular f and so is highly efficient for iterating over xlist and aggregating the output. In other words, this is O(m) rather than O(m*n) in its runtime-dispatch performance.

This is an example of the function barrier trick. The f::F ... where F would ordinarily do nothing, but Julia has special heuristics for function- and type-arguments that avoid specialization in some cases (the number of Real subtypes is presumably limited in practice, but the number of Function subtypes is effectively unbounded so to avoid creating an infinite amount of compiled code Julia just decides not to specialize some code). In this case you may want to disable those heuristics, and adding a type-parameter achieves that. The @noinline is probably unnecessary with modern Julia, but at one point in Julia's development it was important to prevent inlining from defeating your efforts. I'm old-school so I insert these as a precaution.